Bellingham OS9 Users Group - Volume I No. 01 (1990)(Bellingham OS9 Users Group)(US)

as-q USERS gboup

Giffiix, CoCo. Atari, Mac
6809 - 68K OS-9 Level 1. 2, 3

COCO-3 BOOT LIST ORDER BUG
(BLOB)

Facts, fixes and theories

by
Kevin Darling & friends

THE BLOB. Some owners have it, some
have never seen it. Ordering of modules in
a bootlist for os9gen seems to affect it.
Adding new devices may cause it to show
up. What causes it? It's past time to lay out
both what has been conjectured and what is
truly known so far.

At first, the OS-9 kernel itself was blamed.
VeVe been pretty sure nowfor a long time
iiat it is NOT at fault. All the modules are
position-independent, and have been gone
over very closely by several of us , looking for
anything that could cause a problem. We
have found no software cause at all (with
the exception of the disk driver - see below).
Instead, hardware and timing discrepan-
cies in the CoCo-3 and peripherals have
been found almost always to be at fault. In
fact, it's often possible to pinpoint the exact
cause of a particular problem, with enough
information.

Enougli preliminaries. Here are most of
the confirmed and imconfirmed symptoms
and possible reasons, including things that
act like BLOBs...

FLOPPY FORMATTING HALTS IN
FIRST FEW TRACKS; READMrRITES
ARE OFF BY A BYTE:
"en Schunk, myself, and others long ago
ound that the halt method used by
CC3Disk (and some RSDOS drivers in
programs) has a problem with some disk
controllers (apparently mostly pre-19S5

1773's). The usual method is to wait for the
FDC (floppy disk controller) to indicate it is
ready to exchange a byte of data, and then
have the CoCo go into the halt mode. What
will happen is that the first byte transfer
gets lost, and this is returned as a "Read
Error" by the driver.

For reasons as yet unknown, this **data
lost" sequence sometimes "seems" to be
driver position dependent. I would guess
that most boot failures are caused by this
one^ especially with older controllers (altho
I've seen it happen on newer ones, too).
The drivers can be fixed, and we should be
able to post patches later.

READSAVRITES GO TO WRONG LSN:

Actually, they go to the wrong TP^CK,
which is also always the wrong LSN.

Usually caused by using disk drives that are

set to turn on their motors only with drive

select, instead of the required method of all

motors on with the motor-on signal. All

drivers assume that if one motor is on, ALL

are on.

Because of this assumption, and especially

because the drive READY line isn't

usually available on the CoCo setup, the

FDC will send stepping commands

to a drive that is still spinning up again

when selected (it takes about 1/2

second to be actually "ready"),... and those

stepping pulses are totally

ignored by drives not spun up. So while the

FDC _thinks_ it's stepped the

head to a new track, in fact either some or all

of the step pulses have

been lost.

Worse, the 1773 FDC seems to ignore the
imbedded track information on the

disk itself (contrary to docs) and so as long
as the sector nunxber matches up, the data
is read/written. . . to whatever track the head
happens to be over!

So make sure your drive motors all come on
at the same time.

SPEED AND BAD CHIPS
Testing and experiences by several people
has shown that the American semiconduc-
tor industry has gotten pretty bad over the
last few years as far as quality goes. Or per-
haps retailers are selling more reject chips
that they buy on the grey market. In any
case, some failures of chips used in add-on
devices have been found to be brand de-
pendent.

For example, some of the LS245 data buff-
ers inside CoCo-3*s seem to fail to pass true
data at times. Replacing this chip with a
Japanese brand will usually cure this par-
ticular problem. Motorola chips seem to be
the worst bet. Symptom is that an instruc-
tion loop reading from the MPI sometimes
sees bits set that it shouldn't. Solution is to
replace the chip or slow down the loop*
Speedwise, many people use hardware
designed and built for IMhz operation
from the CoCol/2 days. A conunon prob-
lem is with RS232 paks... they may need
the 6551 replaced with a higher speed ver-
sion.

INTERRUPTS

Boot problems also sometimes appear
when a device's interrupt line isn'tcorrectly
reset. I've had several 6551 ACIAs (used in
PS232 paks, etc) thatdecided not to clear
their interrupt line just by resetting the
CoCo. This leaves an interrupt hanging
and can mess up a machine trj^ing to boot

It's also been found that some RS232 paks
were built with the E clock tied to the IRQ
line... this can abort a boot also.

Stuck interrupts are covered in J;he various
"IRQ HACK" files available on most net
works, as are files on the RS232 pak.

MULTIPAK UPGRADE
A non-upgraded MPI definitely causes
problems. At the least, it can cause wrong
information to be read from the crucial
GIME interrupt status port.
The most common rumor we see on BBS's
is that the MPI upgrade "isn't needed",
because **my machine runs fine without
it". DO NOT LISTEN TO THESE
PEOPLE. PLEASE EXPLAIN TO
THEM THAT THEY ARE STUPID.
While we can't swear that you WILL hurt
your GIME if you don't upgrade, we can
certainly say that it does make electronic
sense to DO the upgrade (plus Tandy sold
the upgrades at first cheaper than their
cost, which alone would make one think
there's a good reason for having it, eh?).
The electronic reason for the upgrade i:
this: a READ from $FF80-9F will txim on
BOTH the GIME data bus AND the MPI
data bus. (In addition, really old MPIs ghost
their slot select at $FF7Fand $FF9F, which
causes problems.) It's never a good idea to
have tvt'o devices trying to put data on a bus
at the same time... one of them could get
hurt (usually the GIME, in reported expe-
riences).

Especially under OS-9, where the interrupt
register at $FF92 is re-ad at least 60 times a
second, it makes sense to not have that data
be corrupted by bogus MPI data coming on
at the same time. So UPGRADE YOUR
MULTIPAK NOW!

E-CLOCK SYNCHRONIZATION:
All accesses to peripherals need to use the
6809 E clock to validate the transfer of data
(especially at 2Mh2^). A few early versions^
of third-party devices accidentally were
made with registers that didn't do this. All
have been fixed for a year now, as far as I
know.

Also, sometimes a module (especially
os9pl) will get hit by an errant program,
and then you os9gen a new disk... which
gets perpetuated with the bad os9pl from
then on through newos9gens. We also find
that people often reverify a bad module
quite by accident using disk editors on their
bootfile, thus hiding future trouble. Keep a
log of all changes you make, and CRCs!

MISC THEORIES

Most other problems fall into the mystery
section (meaning we don't have a firm
handle on the caizse yet). I have two pet
ideas that may or may not make sense, but
which are bolstered in part by experiences
by myself and others.

One is that since interrupts cause the inter-
nal BASIC ROM to turn on (to get the
interrupt vectors), the ROM stays on a bit
too long and corrupts the data bxis at times.
Probably a dumb theory <grin>.
The other is that the dead cycles within
many instructions have an effect. During
the dead cycle the address bus contains
$FFFF (which turns on the ROM!) and
again, perhaps this data sticks around, or
the address lines change too fast enough
once in a while from true address to FFFF.
This ties in with partial evidence that some
6809s at 2Mhz will start changing their
address lines immediately after the end of
an E cycle, perhaps even before E-gated
devices finish up . We do know that oddball
reads/writes occur at times to strange ad-
dresses, and this might explain them.
A third theory gaining some acceptance
(but we just don't know how the GIME
works internally) is that the GIME, like the
S ANI chip , powers up using either the up or
down side of the main oscillator clock
(remember hitting reset on SAM machines
to get the right red/blue fake color phase?
likis that). Perhaps one side is better than
the other. Certainly powering down some-
times cures a boot or other problem . So who
knows?

We also know that changing cpu brands,
and sometimes switching GIMEs, will of-
ten cure timing problems and tJiesparklies.
Not always, though.

CONCLUSIONS

We're still gathering data, and occasionally
do run across something unexplained. For
the most part though , BLOBs have become
fairly rare. This may be because people
have more L-II experience, or newer hard-
ware, or a combination.
OS-9 itself is not at fault , and note that even
RSDOS applications can and do suffer
from the same symptoms. The basic answer
is that we moved up to a faster machine,
while still using older peripheral eqtiip-
ment.

Tlie order of the bootlist CAN affect the
symptoms (as we Ve seen), but this is simply
software showing up hardware bugs, and is
NOT the fault of OS-9 itself.
So the final word is this: our best evidence
is that there really _isn't_ a boot list order
bug. Look to your hardware instead.

-kevin-

P.S. The above information has been
gleaned over the past two years from per-
sonal experience, many phone calls and
network messages, and the work of Bruce
Isted, Tony DiStefano, Chris Burke, Roger
Krupski, DP Johnson, Dave Wiens, Ken
Schunk, and many others.

FS: Ifyou have anything to add, please send
information to me at:
76703,4227 - CompuServe
OS9UGPRES -delphi
uunet!76703, 4227@compuserve.com

and More.

Downloadacopyof DIRM. This utility will
display a directory of the memory modules
and which memory block each' module
resides.

NOTE: The following information is con-
tained on the inside back cover of the
DISTO Super Controller II manual. The
author is Kevin Darling and is offered here
in a plagiarized form.

—Rodger Alexander—

OS-9 LEVEL II FORMAT/BOOT
PROBLEMS

When a new bootdisk is made, a boot file is
used. This is a text file that contains the
names of all the drivers and descriptors that
make up your specific bootdisk. The order
in which these drivers and descriptors
appear in this list CAN catise problems.

The symptom is, bootdisks that have
trouble booting up or formatting disks.
The formatting problems are more com-
mon but the cause is not always identified
as a bad boot disk.

Changing the order in which the drivers
and descriptors appear will cure the boot/
format problem . It seems that the RBF and
CC3Disk drivers MUSTre^de in the same
8K block. If you have modified your boot,
installed or patched drivers you may have
caused CC3Disk to drop down to the nexi;
memory block. Usually nxoving the INIT
module from it's present position to the
bottom of the list, works. Remember
though, the OS9p2 driver niust always be
the first on the list. You can change the
order by using EDIT or retyping the whole
file using BUILD then Tise-OS9GEN*td
makeanew bootdisk. Another method is to
actually delete and re-install modules los-
ing EZGEN.

Bellingham 0S9

Fouth Comer 68xxx Mug

Sehome 0S9

"What should we call ourselves? Or does it mailer?
Iffhat does mailer is -whal is our purpose. "Whal is il
Ihal >»e can provide as a group Ihal -we canrol achieve
on an individual basis?

Of course Ihe grealesl advanlage in combining forces
and meeting as a group is the sharing of our common
interest in 0S9. Sharing our knowledge, experience,
and resources to help one another. 0S9 is a powerful
system that is growing world wide and with the advent
of the 05-9000 for the 80486/66030-40. we have a lot
to look forward to.

PH^EFITS:

Qub Public Domain Library

Access to the Gimix multi- tasking 0S9 system

Group purchases at discounted prices

Monthly Users Meeting at Sehome High School

N^3 Letter

Barbequed RBBS 0S9 Conference. Bulletins and 350
Downloads

Demonstrations and Guest Speakers

Stale-wide 039 User Groups

CoCo/OS-9
Software - Hardware

CoCo Hardware/Software

PERSONAL COLOR RADAR (Vidlex package for down

loading radar weather fax)

MATH TUTOR (Rom Pak) ..

^.DDIO SPECTRUM ANALYZER (Rom Pak)

fflCRO wms DS-es digitizer

8S9TRSCOR^

fifW TKSFDIT

PraaSION TIME MODULE (Real Time Oock Rom Pak)

ZOKO RAN Rom Pack

GHANA BWANA (039 Disk Game)

SUPER SCREEN MACHINE (Disk)

eOLORCOM/E (Disk)

S.ANDS OF EGYPT (Disk)

ONE ON ONE (Basketball Game-Disk)

BIOSPHERE Game (Disk)

FLJPSIDE Game (Tape)

DALLAS QUEST (Disk)

POOY.AN (tape)

FUL-O-PAJi (0S9 level-1 screen utilities)

RS-232Pak

TELEWRlTER-64 lordprocessor (CoCo 1-2)

DATAPEN yght Pen (tape)

MAGI-GRAPH (Disk)

gflPER PITFALL (Rom Pak)

MICRO ILLUSTRATOR (039 Disk)

PlTFALL-11 (0S9 Disk)

JfEGA-BUG (Rom Pak)

MUSIC (Rom Pak)

PEANUT BUTTER PANIC Game (tape)

CASTLE OF THAROGGAO (Rom Pak)

PEGASUS (0S9 Disk)

DESKMATE (0S9 level-1)

HIGH RESOLUTION JOY SHCK

RADIO BALL Game (tape)

DIAGNOSTICS (Rom Pak)

DUNGEONS OF DAGGORATH (Rom Pak)

GOMOKU/RENJU (Rom Pak)

CANYON CUMBER (Rom Pak)

bask: 09 (Level-; Disk)

TETKS (iftHB f^i

Osy Levei-I

FLIGHT SlMULATOR-1

PERSONEL FINANCE II (Rom Pak)

X-PAD

Januan Meeting
Sehome H.S.

Jan, 11 7;30p.m.
(room 109)

Agenda:

Wes Payne has been working on an E-mail type
of security message base for 0S9 using Basic09.
Wes will demonstrate and explain the process
involved.

Wes has also set up special "USER GROUP"
access directories on the Gimix.

Documentation and manuals will be available
to help us answer the remaining questions
regarding RMS and the INTROL C Compiler.

A demonstration of some recent utilities that
have become a must in solving the Boot Order
Problem referred to by Kevin Darling at the
beginning of this Newsletter.

Group Goals need to be addressed at this
meeting-

And hopefully even more CoCo / 0S9 Stuff for
sale should be available for viewing and pur-
chase.

z o

— ,y 2 f. 1-1 ?

>-

K
to

G)

CM

»—

00

OJ

J

» «W M M

liJ

>

U

J

• (0

fr

OJ

LJ

,-

$

°,

1

r

0)

1

<

-

GO

1
<

1
<

1
<

o

UJ

I

CQ

1
<

n
<

OJ

1
<

1
<

CD
Z

a.

i

t-
z

ID
Q

D
h

UJ
J,
U
<

h

a
o

Q.

o

h

3

I

111

h